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EXECUTIVE SUMMARY 


TITLE: Cheyenne Mountain System Acquisitions: 

Problems and Principles 

AUTHOR: Ellis K. Conoley, Lieutenant Colonel, USAF 

Acquisition of computer systems for the NORAD Command 
Post at Cheyenne Mountain has been problematic throughout its 
entire history. The acquisitions have been characterized by 
unrealistic specifications, budget overruns, slipping schedules 
and ill-defined responsibility in each of the three historical 
programs—NOCOPS, 427M and the Cheyenne Mountain Upgrades. When 
problems were encountered in each of these phases, intervention 
by high command levels was necessary in order to achieve 
operational capability. An historical study of these problems 
and solutions leads to principles which were shown to work in 
the Granite Sentry Program, and which should be required in 
future Cheyenne Mountain acquisitions. - 
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in Computer Science from the University of Texas at Austin. 

From 1977-1985, as a computer software project manager, he 
monitored the implementation of the 427M system, and he was 
involved with upgrades to radar and optical systems which 
interface to NORAD. From 1986-1987, at HQ AFSPACECOM, he was 
the branch chief over the development of CSSR and CCPDSR. 
Finally, from 1987-1989, the author was the project leader for 
the AFSPACECOM Granite Sentry Development Office. Thus, the 
author has had the opportunity for over 17 years to observe 
various phases of the development and implementation of the 
increasingly complicated Cheyenne Mountain computer support 
systems. 
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PREFACE 


Over the last 17 years-, my service career has provided 
me with direct, personal experience with all three of the major 
phases o-f the NORAD computer systems. As a user in the original 
NORAD Combat Operations and Space Defense (425L/496L) system, I 
witnessed the difficult implementation of its replacement, the 
427M system. After the notorious false events of 1979 and 19E0, 
I was a low level participant in the investigation team which 
recommended improvement of test control procedures. 

For six years of working on programs which interfaced 
with the 427M system, I observed the Cheyenne Mountain Upgrades. 
For 6 months in 1986, I supervised the harassed AFSPACECOM 
managers who simultaneously were attempting to get the CSSR 
Block I on line, were answering GAO complaints, and were 
assisting their Electronic Systems Division counterparts in 
getting the CSSR Block II on contract. During that time, we 
discovered that no one possessed a complete copy of the CSSR 
specifications—not even the contractor who was bidding an old 
specification. Requirements for the replacement system could 
not be articulated because the user who specified them could not 
be identified. By August 1986, Cheyenne Mountain programs were 
a source of frustration to all interested parties. 
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Soon after it was established, the Air Force Space 
Command was directed to accomplish Branite Sentry on time, 
within budget, and by ourselves if necessary. I was placed in 
authority over that program and was tasked along with Lieutenant 
Colonel Pete Maravelias and Captain Steve Shively to work out a 
plan that would be successful. Fortunately, we had the devoted 
help of Major Generals Spraker, Brandt, Cassity, and Clark as 
well as then Colonel Gray. Their interaction, insight, and 
foresight forged the agreement which allowed Granite Sentry 
Phase I to reach operational capability. 

These personal experiences have led me to investigate 
the historical environment of Cheyenne Mountain in an effort to 
understand the factors which have made the development of 
computer systems for the mission so difficult. Valuable 
insights into these problems have been made at each stage of 
the acquisitions. It is my hope that these principlc-s may be 
used to formulate a model for successful future acquisitions. 


Acknowledgment: A special gratitude is due my brother Patrick 

who was a tireless editor. 
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CHAPTER I 


INTRODUCTION 


The North American Aerospace Defense Command (NORAD), a 
bi-national United States and Canadian command, is responsible 
for detecting an air or missile attack on North America, assess¬ 
ing the nature of the attack, and notifying United States and 
Canadian leaders of the attack. This mission is accomplished 
through a system of space and air surveillance sensors, communi¬ 
cation devices, and computers which pass data to information 
processing centers at Cheyenne Mountain Air Force Base near 
Colorado Springs, Colorado. These centers pass the processed 
surveillance information to the NORAD Command Post (NCP), also 
located within Cheyenne Mountain. The duty of the Command Post 
is to assess the information it has received and to complete the 
proper notification in a timely manner. The successful 
functioning of this warning system is a pillar of deterrence. 

The command centers in Cheyenne Mountain are operated by 
the United States Space Command (USSPACECDM), a unified command 
made up of the Air Force Space Command (AFSPACECOM), the Army 
Space Command, and the Naval Space Command. Located at Peterson 
Air Force Base near Colorado Springs, USSPACECOM is responsible 
for ensuring that NORAD is supported with the computer systems 
it needs to perform its critical warning and assessment mission. 
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AFSPACECOM implements the support, and the Electronic Systems 
Division (ESD) o-f the Air Force Systems Command (AFSC) serves as 
acquisition agent. 

Historically, NORAD computer acquisitions have been 
characterized by changing requirements, schedule delays, and 
budget overruns. These have led to repeated investigations by 
Congress, by the United States General Accounting Of-fice, and by 
Department o-f Defense agencies. This paper discusses the 
history of these acquisitions in order to understand the factors 
which have contributed to these problems and to determine 
principles which, if implemented, may improve the acquisition 
process. 


Problem Statemen t 

What factors historically have contributed to 
problems with Cheyenne Mountain system acquisitions? 

What principles historically have been successful 
and may contribute to future successful 
acquisitions? 


Assumptions 

Recently, investigators have attempted to measure the 
success of programs by cost effectiveness, i.e., fielding a 
system as capable as possible, as close to schedule as possible, 
and for the appropriate cost. (1:28) These criteria are used in 
this paper to measure the success of a program from the manage¬ 
ment point of view. The operational measure of a successful 
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program is, however, subjective. If the system does not meet 
the user's basic needs, then meeting the job specification on 
time and within budget does not matter. The user must be 
satisfied. 


Limitations 

The author's years of involvement with the Cheyenne 
Mountain computer systems provide a unique, personal point of 
view for this study. Many statements are based upon personal 
observation and are difficult to verify independently. Also, 
the author's involvement with a relatively successful phase of 
the upgrade program introduces some bias. Similarly, hindsight 
bias can perturb analysis in a field of rapidly changing 
technology such as computer science. (2:22) It is hoped that 
careful analysis will minimize these potential problems. 

Organizations and relationships in these acquisitions 
are extremely complex. To some extent, they have been 
simplified to make the subject comprehensible by the general 
reader. 

There are limits to what can be done in a short time by 
a single researcher. There is a wealth of writings on program 
management, software development, and leadership. Even after 
the effort spent by this researcher, some excellent advice 
pertinent to environments like Cheyenne Mountain may have been 
missed. 
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Background In-format ion 


Command and control systems have several -features which 
distinguish them from other systems. These systems are software 
dominated and are generally implemented on commercial aff-the- 
shelf hardware. (3:20) They are one-of-a-kind systems with the 
development model being the final operational product. (3:19) 
They are information systems which must perform acceptably with 
imperfect information and which must degrade gracefully under 
stress. (4:5) They greatly reflect the personality of the 
commander using them and therefore require flexibility. (4:5) 
Success of command and control systems is difficult to define 
because performance measures for these systems are ultimately 
subjective. (3:19) Finally, these systems are typically 
embedded within a larger framework of interconnected systems. 

(3:19) 

Complex systems historically have been implemented by 
either a conventional or an evolutionary acquisition strategy. 
The c onv e ntional strategy is designed for systems with well- 
understood requirements needing little refinement during 
development. "A conventional acquisition strategy requires a 
detailed definition of the capabilities and characteristics of 
the entire system before starting full-scale development." (4:6) 
This strategy produces turnkey systems, which are intended to be 
finished products. Conventional strategies have traditionally 
been overseen contractually by the military, but have been 
managed by civilian agencies who are contracted to deliver the 
specified product. With civilian contractor management, changes 
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in the program require renegotiation of the contract. 

The evolutionary strategy is designed -for systems which 
will change, or evolve, during development but which remain 
within a defined architectural -framework. (4s 3) An evolutionary 
strategy addresses 

... the need to field a well-defined core 
capability quickly in response to a validated 
requirement, while planning through an 
incremental upgrade program to eventually 
enhance the system to provide the overall 
system capability. (4:3) 

With evolutionary acquisitions, management by the military is 
possible with contractors responsible for specific tasks within 
the greater acquisition. 

For NC1RAD systems, when Air Force Systems Command (AFSC) 
is the acquirer, a System Program Office (SPO) is assembled with 
the SPO director as the single agent responsible for 
acquisition. (5:8) When Air Force Space Command (AFSPACECQM) is 
involved with an acquisition, a Command Manager (CM) represents 
AFSPACECOM on all matters relating to the acquisition. (559-10) 

Contents 

This examination begins in Chapter II with a history of 
the original NORAD Combat Operations System (NOCOPS, or 425L) 
and the original space defense computational system (496L). 
Chapter III treats the CheyBnne Mountain Improvement Program 
(427M) which replaced the original programs. Chapter IV begins 
with the Cheyenne Mountain Upgrades which are designed to 
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replace 427M and concludes with the formulation of the Granite 
Sentry agreement. Chapter V presents the principles 
incorporated into the plan for the Granite Sentry acquisition. 
Chapter VI covers the implementation through 1989 of Phases I 
and II of Granite Sentry. Each of the foregoing chapters 
attempts to elucidate the factors which have complicated and the 
principles which have facilitated the acquisition process at 
each stage. Chapter VII summarizes the principles learned from 
this historical analysis and which, if implemented, may help to 
structure a better Cheyenne Mountain acquisition model. 



CHAPTER II 


THE ORIGINAL SYSTEMS 

There are three historical stages of the Cheyenne Moun¬ 
tain information system. The first stage was the 42SL NORAD 
Combat Operations System (NOCOPS) and the associated 496L space 
defense computational system. These, and other related systems, 
were hosted on multiple processing units. The second was the 
Cheyenne Mountain Improvement Program (427M), a relatively mono¬ 
lithic system which replaced the first system in 1979. The 
Cheyenne Mountain Upgrades, which includes Granite Sentry, is 
the third stage which is currently replacing 427M by a 
distributed architecture system. This chapter discusses the 
development of the original 425L. and 496L systems. 

In 1959, the Air Force began to construct a survivable 
Combat Operations Center (COO to house the operational NORAD 
centers. (6:2) (7:1) These included the NORAD Command Post, the 
Battle Staff Support Center, the Weather Support Unit, and the 
Air Defense Operations Center (ADOC). An information processing 
system, designated 425L, would be developed to support the COC. 
All of the centers would have appropriate communications links 
as well as closed-circuit television displays. (7:2B) 

Through 1959, the Air Force mission of the COC was to 
counter a manned bomber threat. However, with the increasing 
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missile threat at the turn of the decade, Headquarters USAF re¬ 
directed planning to stress missile attack warning and space 
computation. (6:2) The Air Force planners were thrust from a 
comfortable, wel 1-understood bomber defense to one involving 
concepts and software which had not yet been developed. 

Recognizing the problems inherent in developing complex 
systems, the Department of Defense commissioned the 1960 Winter 
Study Panel to overview the issue. The panel expressed concern 
over the difficulties of integrating systems m the absence of a 
consistent set of operational objectives and standards for 
system design. (8:2) It recommended an evolutionary acquisition 
approach for one-of-a-kind systems. (8:1) Following the Winter 
Study recommendations, requirements dated 19 June 1961 directed 
that 425L be acquired in a five-phase evolutionary manner, that 
an experimental test facility be constructed, and that the pro¬ 
gram be managed by the military. (6:3) The program would 
utilize commercial off-the-shelf equipment from industry or from 
government sources. (6:3) (7:27) Two not-for—profit 

corporations, the MITRE Corporation and System Development 
Corporation, were designated as system designer and software 
developer, respectively. The Electronic Systems Division (ESD) 
of Air Force Systems Command (AFSC) would serve as acquisition 
agent for the project. 

For the next four years 425L was evolved through four 
pre-operational phases. Several other programs under 
simultaneous development by other governmental agencies were 
required to be included in the COC and to be integrated with the 


425L system. (6:3) These programs were the Defense 
Communications Agency communications processors, the 
Intelligence Data Handling System (IDHS), the Ballistic Missile 
Early Warning System (BMEWS) Display Information Processor 
(DIP), a display distribution system, and the closed circuit 
television system. (40:6) As a result of the diverse programs, 
independent organisations, and interfaces, the equipment 
configuration changed many times. (7:36) Other changes 
concerned how the space tracking system, 496L., would interface 
with the 425L system. The agencies involved with NDRAD could 
not agree on the integration requirements or a baseline, 
resulting in halting progress, program slips, and increased 
cost. (7:36) 

Progress on Cheyenne Mountain integration languished. 

On 29 October 1963, the US Department of Defense Office of 
Development, Research and Engineering brought its concern over 
the changing requirements, increasing costs, slipping schedules, 
and integration problems to the attention of the Secretary of 
Defense. <7:27) In December, the Secretary directed CINC NORAD 
to appoint, the Cheyenne Mountain Complex Task Force to study in 
depth the "requirements, technical design, operational plan, and 
acquisition management for the NORAD COC complex of systems in 
Cheyenne Mountain." (42:44) The term "Cheyenne Mountain 
Complex" (CMC) was formalised to mean all of the computer 
systems within the mountain. (7:27) The task force recommended 
that a single agency be appointed responsible for Cheyenne 
Mountain integration. (41:74) 
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As a result, the Secretary of Defense directed the form¬ 
ation of the Cheyenne Mountain Complex Management Office 
(CMCMO), a single manager responsible for bringing the COC to 
initial operational capability (IOC). The CMCMO was headed toy 
an ESD officer with a NORA!) deputy. (4Is7*1; The ESD Program 
Director reported to the ESD Vice Commander. (9:44) The NORAD 
Deputy personally represented CINC NORAD. (7:39) With the 
exception of the contracting officer, the entire team was 
located in Colorado Springs. Other implemented recommendations 
were a finalised, baseline equipment configuration, the 
separation of missile warning from space defense, and the 
continuation of the experimental test facility. (7:40) 

With the formation of the CMCMO in July 1964, the in¬ 
dividual programs began to see real progress. Within 18 months, 
the 425L system reached IOC. (6:4) In all, eleven other systems 
were integrated with 425L over the next four years, including an 
early version of the Command Center Processing and Display 
System (CCPDS) which was necessary to provide a catastrophic 
failure backup for 425L and the DIP. It also gave CINC NORAD 
the same display of the same information seen in the Strategic 
Air Command (SAC) comm-V’.: pafct. Interface to 496L, however, 
remained manualj 

In its Ches'enne Mountain Complex Final Technical Review 
(CMCFTR) of May 1966, the CMCMO summarized the key points which 
finally led 425L and 496L to successful completion, and it re¬ 
commended that they be used in similar programs in Lhe future. 
Sy stem flexibi lity was essential because of constant change in 
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the world environment and because of changes in the interfaces 
dictated by changing system users. (6:26) The evolution a ry 
growt h c onc ept v^s a major contributor to success. There must 
be sufficient a • between stages to allow lessons learned in 
one stage ti- c* x porated in the next. (6:2B> O perational 
test - beds and a -:ock-up of the command post should be located 
close to the usv . but remain under the developer's control to 
prevent the use*. .. oai ufc'ing the tesc-bed operationally and 
interfering with testing. (6:26) The design, r-ardware, and 
contractor management should be be controlled by the military 
rather than by contractors. This approach was perceived to give 
maximum effect for minimum dollars expended. (6:28) Finally, a 
sizeable detachment of the program office should be c ollocated 
with the us er. Collocation reduced response time and 
facilitated turning the system over on schedule. (6:28) 

In summary the system was a one-of-a-kind product which 
pushed the state of the art of computer science. Performance 
requirements were changing during implementation, and interfaces 
were challenging due to the use of multiple hardware types. 
Management was fragmented with unclear channels of 
responsibility and authority to see that the program was 
executed. The Secretary of Defense directed formation of a 
single management organization which brought the SPO to the user 
and the original systems to operational status. 
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CHAPTER III 


THE CHEYENNE MOUNTAIN IMPROVEMENT PROGRAM 

As '.he 425L and 496L systems reached IOC in 1966, there 
were f-ojections of growing So\iet ballistic missile 
capabilities and a steady incr -ase in the number of earth 
orbiting objects. Within a decade, <he existing systems would 
be inadequate for NORAD's mission requirements. (10:7) Further, 
the equipment w«us first generation, transistor vintage. As it 
aged, there would be growing problems with reliability and parts 
.availability. Finally, Cheyenne Mountain had no uninterrupted 
power supply; power fluctuations within the CMC had damaged 
system ardware, sometimes with loss or alteration of data. 

(10:7) Consequently, in June .1969, NG*> "D began formal planning 
of the Cheyenne Mountain Improvement Program 427M, a replacement 
for 425L, 496L, the Display Information Processor, rd their 
communications systems. This replacement was though, to entail 
a simple rehosting of existing software to more capable 
computers. (11:25) After the rehosting reached IOC, the program 
would evolve whatever additional capabilities were needed. 
Unfortunately, the contracting structure did not support the 
evolutionary phase of the effort. (12:85) 

In order to address the previous problem of multiple 
interfaces, 427M was designed to be more monolithic than the 
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distributed systems it replaced. The number of mainframe 
computers would drop from 11 to two. These two machines would 
perform all of the space, air, missile warning, and command and 
control functions. (11:25) This approach appeared valid since 
the computer systems of the era far exceeded the memory and 
processing capabilities of the original systems. Using only two 
mission machines would also minimise cost. The Department of 
Defense specified that the computers be Honeywell mainframes, a 
business-oriented system used in the World Wide Military Command 
and Control System (WWMCCS). (11:38) 

Oncp again, as with the 425L acquisition, the 427M 
System Program Office (SPO) office was established at ESD in 
Massachusetts rather than in Colorado Springs. (11:45) In 
October 1969, citing the {success of the CMCMO, NORAD requested a 
permanent ESD presence in Colorado Springs. (11:45) 

Consequently, AFSC and EfSD renamed the 425L/496L Field Office as 
the 427M Field Office, but did not give it any decision-making 
capability or local engineering support. (11:45) The SPO 
remained in Massachusetts, 

In 1971, MITRE, ESD, and NORAD jointly published the 
technical requirements which defined the specifications for 
contractors bidding on 427M contracts. The program was par— 
titioned into three maj.,.- segments, all of which would be de¬ 
veloped simultaneously. The NORAD Computer System (NCS) wi,..*d 
replace the 425L system, the DIP, and the CCPDS, consolidating 
missile warning functions into one system. (10:9) The Space 
Computational Center (SCC) would replace the 496L system. The 
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communications processors and technical control would be 
replaced by the Communications System Segment (CSS). Each of 
these systems would be connected to display consoles via a 
modular display system, and the existing closed-circuit 
television and large group displays would be inter-faced to the 
427M system. 

Software contracting for 427M was cumbersome. (11:34) 

In October 1972, the Philco-Ford Corporation was awarded an 
overall 427M integration and communications contract. System 
Development Corporation won the SCC contract in early 1973. 
System Development was also responsible for the hardware for the 
display system which Ford would have to integrate. (13:1328) 
NORAD would provide the software for the NCS. 

Within a few months. Ford had subcontracted to System 
Development for software work, and System Development had sub¬ 
contracted to Ford for software work! (10:33) Contract admini¬ 
strators were fearful that efforts would be confused, and the 
Defense Contract Audit Agency saw the reciprocal arrangements as 
an opportunity for overcharging, fraud, and finger—pointing when 
the schedule slipped. (10:36) However, the arrangements had to 
continue lest the program lose time during recompetition. 

In 1974, ESD predicted a program slip and cost growth. 
AFSC determined that a third mission-processing node would be 
required to meet the processing and availability requirements. 

It also recommended improvements in the contractor—to-SPO com¬ 
munications and that NORAD assume more of the software develop¬ 
ment tasks. Funding was increased, the schedule was slipped, 
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and the third node was added. However, the recommendations for 
software development and improved communications were not 
followed. (11:25) 

In 1975, the program office announced a further slip. 
NORAD again insisted that the SPO be located at Colorado Springs 
and that it be given decision-authority. NORAD also insisted on 
close coordination with ESD and close, consistent direction of 
the contractors. (11:55) AFSC agreed to move 427M program man¬ 
agement to Colorado Springs, but kept its business management in 
Massachusetts. AFSC would retain overall project authority, and 
NORAD would perform more programming in-house. (11:55) 

The requirements of the program were prioritized so that 
the software teams could concentrate on the essential. NORAD 
assumed responsibility for the NCS software integration, for SCC 
software, and for CSS expansion software. It increased its role 
in testing 427M, it deleted a major requirements package in a 
common display set which was to reside on the SCC, and it agreed 
to an earlier implementation. (11:55) Finally, the SCC contract 
was restructured according to NORAD direction. (11:56) In 
short, 427M was modified to be a design-to-budget effort. 

(11:55) The baseline, however, was not yet frozen. (11:56) 

Work progressed on the individual pieces of 427M. Even 
though the WWMCCS equipment was ill-suited for the job, it was 
beginning to function, although not to performance 
specification. In 1976, NORAD raised 427M to first priority 
status, (11:61) and all NORAD program management was 
concentrated under a single manager as Assistant to Vice CINC 
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ADCOM (the USAF component of NORAD) tor 427M. (14:65) In April 
1976 NORAD assumed responsibility for system engineering, 
integration, and test for the entire 427M system. (11:62) MITRE 
performed as system engineer for NORAD and provided engineering 
support to ESD. ESD maintained responsibility for the CSS 
program. (10:33) 

In 1977, the program failed a major milestone when the 
CSS was not ready for testing as a complete system. As a 
result, NORAD requested an Independent Review Broup (IRG) to 
assess the program. The IRG noted that management had been 
fragmented— there was no single point of contact for the 
program. Guidance to software developers came from several 
NORAD organisations, and differing direction arrived from ESD.- 
(11:64) (13:1328) The IRG concluded that 

joint management of 427M Chad! hampered the 
program's progress. ESD's integration role was 
very narrow and inadequate from a systems 
viewpoint. CNORAD] was without a systems 
engineering resource ... The divergent interests 
and the difficulties encountered [indicated! that 
total management responsibility should be vested 
in a single authority. (10:32) 

Finally, recognizing the difficulty of meeting the over— 
stated specification and matching the performance of the 
original systems, the IRG concluded that 427M should be declared 
operational when it reached an e quivalent f u nctionality with the 
old system. This state was referred to as "equivalent 
operational capability" (EOC). (11:38) Following the IRG's 

recommendations, CINC NORAD agreed to take operational control 
of 427M and bring it to EOC with continued MITRE engineering and 
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ESD contract support. (11:65) 

CCPDS was originally intended to be replaced as part of 
427M. However, 427M did not meet the availability of the old 
systems, and the need for a more available missile warning func¬ 
tion was apparent. Two programs were produced to ensure near 
continuous missile warning availability. The first was the 
Mission Essential Backup (MEBU) software which was hosted on the 
CCPDS computers. (11:57) The second was the Missile Warning 
Bypass (MWBP), a communications system which bypassed CSS. 

While there were reasons for building these systems, no criteria 
were given for an availability of 427M which would allow their 
elimination. 

The 427M system requirements were an excellent example 
of the "second system effect". (15:55) The first system built 
to perform a task is usually constructed carefully and with re¬ 
straint. The second, or replacement, system, however is usually 
overdesigned. All the frills and ideas which were set aside on 
the first system tend to be included in the second system. 

(15:55) These additions, plus the natural tendency to produce a 
perfect system, can lead to impossible requirements. The 
original 427M specifications simply were not attainable with the 
technology of the times. (13:1327) Compounding the problem, 
continued software baseline changes had improved 425L and 496L 
so much that by 1977, when 427M arrived at 1974-level 
performance, the new system was three years of changes behind. 
(11:23) The defining of "Equivalent Operational Capability" by 
the IR6 was an acknowledgment that 427M was far short of the 
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requirements. 

In summary, limitations of a business computer system, a 
limited commercial operating system which had to be enhanced in 
mid-stream, and the addition of non-WWMCCS interface computers 
were significant obstacles. The NORAD programming agency con¬ 
tinued to release versions until 1977. Contractors proceeded 
with the bidding, hoping that engineering change proposals (ECP) 
would correct financial as well as schedule problems. (13:1327) 
But the entire original CMC system could not simply be rehosted 
to a modern computer system, and the requirement to automate the 
original space manual operator functions and display functions 
was beyond the scope of 1970's technology. (10:215) The assump¬ 
tion was erroneous that a modern, time-sharing system could 
exceed the capabilities of the 11 distributed systems of the 
vintage mountain. Specifications were not adjusted to the real¬ 
ity of the hardware and software system until near the end of 
the program. However, in three extra years, with twice the 
originally budgeted funds, and under the criticism given by 
numerous monitoring agencies, 427M eventually reached the first 
stage of its evolution, EOC, in September 1979. 

Thus, the 427M acquisition suffered from many of the 
same problems as the original system. There was no single 
authority to ensure execution of the over—ambitious, 
one-of-a-kind project with rapidly changing requirements whose 
management was located remote from the user. NORAD involvement 
escalated until it was responsible for integration and all of 
the software except communications. Bringing 427M to EOC 
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reqi red user involvement in a single integration organisation, 
mov: g a portion of the SPO to Colorado Springs, and military 
management of the contractor resource by both ESD and NORAD. No 
real progress was made until the user component was moved under 
the Vice Commander. 
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CHAPTER IV 


THE CHEYENNE MOUNTAIN UPGRADE PROGRAMS 

On 9 November 1979 and again on 3 and 6 June 1900, the 
427M system transmitted missile attack indication messages to 
SAC and to the National Military Command Center in Washington. 
Consequently, 427M became the subject of a series of 
investigations which concluded that the fragmented management of 
its acquisition was a prime reason for its problems. (16:13) In 
the paper, NO RAD C omputer S ystems a re Dange rous ly Ob solete, the 
House of Representatives confirmed that 427M needed to be 
replaced. (17:17) The replacement programs for the 427M system 
were designated the Cheyenne Mountain Upgrades (CMU). (10:1) 

The upgrades-were to implement a distributed architec¬ 
ture tied together by a robust Communications System Segment 
Replacement (CSSR). The CSSR would handle all CMC internal and 
external data communications with the exception of certain 
intelligence information. (19:13) Missile warning functions on 
the NORAD Computer System (NCS), the Mission Essential Backup 
(MEBU), and the Command Center Processing and Display System 
(CCPDS) would be replaced by the Command Center Processing and 
Display System Replacement (CCPDSR). Space surveillance 
functions would be replaced by the Space Defense Operations 
Center (SPADOC). The formal program start was early 1901, with 
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a scheduled completion of March 1987. (17:IB) The remainder of 
the NCS functions of Battle Staff Support, Weather, Air Defense, 
the NORAD Command Post, and the production of integrated 
displays were to be consolidated into the NCS Replacement 
(NCSR). (10:4) A conventional strategy was selected for the 

CSSR, SPADOC, and CCPDSR acquisitions. Each of the System 
Program Offices was located in Massachusetts. The acquisitions 
were to be turnkey, but were to be acquired in increments. 
Specifications were written, competitions run, and contracts 
awarded. 

Immediately, CSSR began to experience growth in require¬ 
ments and cost. By 1989, the cost of the program had risen from 
$202 million to $350 million. The IOC for Block I slipped to 
1990. Block II was awarded in February, 1987, with IOC 
scheduled for 1991. (19:27) Thus, conceived in 1981, CSSR will 

take as long to develop as the entire 427M system. SPADOC was 
conceived as a rehosting followed by a four—phase evolution. By 
1989, SPADOC had increased in price from $290 million to $487 
million, and the IOC had slipped from 1988 until 1994. SPADOC 
will take almost a decade to complete. (20:48) In 1987, the 
CCPDSR operational date was slipped until 1992 in order to 
accommodate the rising program costs of SPADOC and CSSR and to 
avoid the turmoil of having too many programs in simultaneous 
test within the CMC. 

As a result of the development problems, the US General 
Accounting Office (GAO) investigated CMU in depth. The GAO con¬ 
cluded that the use of commercial off-the-shelf operating 
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systems for CSSR caused an unacceptably slow restart from a 
power outage. Further, CSSR could not meet the required message 
throughput, and wiring and message standards were lacking for 
communication among programs. (19:4-6) GAO further observed 
that technical control was at its growth limit, and that the 
users and acquirers did not agree on the specifications of the 
system. (19:21) The GAO noted computer security problems in 
SPADOC Block 4. (20:48) After seven years of development, the 

system did not meet 14 of 23 performance requirements. (20:13) 
The entire CMU was criticized as having no single organization 
truly in charge. (17:23) The report ackowledged that the 
problem resolution structure documented, formally tracked, and 
discussed problems, but emphasized that it did not often resolve 
them. (17:23) 

The lists of problems constituted a repeat of the 427M 
difficulties couched in the computer specifications of the 80s. 
The "second system" problems of automating the man-machine 
interface and integrating man missions on a single system 
unsuited for the job were reborn. Color graphic displays were 
asked to switch as fast as a monochrome system to display a 
database one thousand times as large. Sophisticated custom 
computer security enhancements slowed the basic system down to 
the point that almost no work could be performed. The modern 
operating system of perhaps a billion instructions was expected 
to load as quickly as its 1960s counterpart of 3000 
instructions. Pressing the state-of-the-art caused the 
contractors repeatedly to redesign and augment the commercial 
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software. 


Software maintainers numbering several hundred Air Force 
and contractor personnel were experts on the current systems 
which they had maintained for 10 years. The maintenance organ¬ 
isation could make gigantic changes in a single release. 
Improvements in 427M made it perform almost as well as, if not 
better than, the replacement, exaggerating tho user's 
expectations for the replacement and setting the stage for 
disappointment. (19:27-29) The specified capabilities for the 
CMU did surpass those of 427M. For example, the CSSR is 
specified to exceed the existing CSS in 10 critical areas. 

(21:7) Unfortunately, the CSSR has not yet been proven, and it 
will have a hard test against the mature 11 year—old system. 

The interface among systems was designated a potential 
problem area in 1982 by a review committee called for the 
purpose of exploring the risks and benefits of a distributed 
processing system. (22:2) Standardization in message protocols 
and formats was cited as critical for implementing the 
architecture. Unfortunately, the CSSR, SPADOC, and CCPDSR 
programs went on contract with different message sets and 
protocols. (17:24-25) 

The most condemning criticism was that there was no 
single entity in charge of either the 427M development or of the 
current modernizations. (17:3) Numerous agencies were in 
charge, but none truly responsible for success. The current, 
traditional program organizations did not readily share risk and 
success as did the final CMCMO and 427M organizations. A 19B3 
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attempt to reestablish a single manager -for the CMU resulted in 
the management being assigned to the Systems Integration Office. 
(23:1) That agency was responsible for CMU interface and 
certification standards, but it could only enforce standards 
indirectly by refusing to certify a system. (45:3) Thus, the 
CMU was experiencing problems similar to the previous systems. 

In May 19S3, plans for the NORAD Computer System Re¬ 
placement (NCSR) began to be coordinated through the NORAD 
staff. The goals for the NCSR were minimal operational risk, an 
achievable schedule, and interfaces to other programs. (24:1) 

The NCSR was planned to begin in 1986 with IOC in 1980. As with 
the 427M acquisition, the schedule was short because the task 
was seen by NORAD to be a software rehosting effort. (25:1) By 
February 1984, HQ Air Force Operations Plans questioned the 
optimistic schedule. (26:1) By April 1985, ESD provided the 
first cost estimate of $489 million. General Herres, CINC 
NORAD, questioned both the architecture and the cost, insisting 
on "clearly defined program objectives broken down into 
sequential implementation packages." (27:1) 

The SPO then proposed an incremental development which 
would begin with the Air Defense Operations Center (ADOC) in 
1986, but which included no schedule for the NORAD Command Post, 
the Battle Staff Support Center, or for the Weather Support 
Unit. Each of these programs was to be a separate, future 
acquisition. Questioning the three-year ADOC schedule and the 
number of acquisitions, CINC NORAD directed his staff to examine 
alternative ways of executing the NCSR. Consequently, the 
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remaining functions—Battle Staff Support, ADOC, and Weather 
Support—were consolidated into the Branite Sentry Program in a 
statement of need written 19 July 19B5. (28:1) 

Meetings at all levels during the fall of 1986 resulted 
in an agreement between CINC NORAD and the commander of ESD. 
Branite Sentry would be executed in an evolutionary fashion, 
with each phase building on the previous phase. Represented by 
ESD and AFSPACECOM, the Air Force would be the military manager 
for the project. Both commands would function as overall risk- 
takers. (29:49) ESD would provide program support and manage¬ 
ment, and AFSPACECOM would develop the software. (29:49) (30:7) 

Both commands would contribute other support as needed to ensure 
priority execution. (30:10) Although these tasks might be ac¬ 
complished with contract support, responsibility would clearly 
fall on the appropriate military organisations. (29:49) Most 
important, ESD was identified as the single agency ultimately 
responsible for execution. ESD would assist in program advocacy 
and would be the final arbiter of schedule and cost discussions. 
In a sense, AFSPACECOM would act as a software and systems con¬ 
tractor to ESD. This arrangement ensured that one agency was in 
charge of the program, but it incorporated shared risks and 
responsibilities. The initial cadre of AFSPACECOM developers 
was tasked to work out the mechanics of the program with the ESD 
SPO. 
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CHAPTER V 


GRANITE SENTRY PRINCIPLES 

From November 1986 until March 1987, the AFSPACECDM and 
ESD components of the newly formed Granite Sentry Cadre met to 
finalise the ground rules for implementation. ESD would provide 
a program office in Colorado Springs with its deputy and other 
personnel collocated with the AFSPACECOM development office. 
AFSPACECOM would enhance the initial staff of eight pi-ogrammers 
with a programming ..earn of 40 beginning in January 1987. (31s 1) 
The key personnel from both commands were to be frosen for four 
years, thus ensuring continuity of management and a consistent 
viewpoint. (30:7) The program would be executed within the 1987 
budget of $141 million through 1991, and ESD would not make 
funding adjustments without AFSPACECOM concurrence. (30:15) The 
problems of changing baseline and interface requirements were 
addressed by limiting 427M version releases to one per year. 
Emergencies, of course, would be excepted. (30:7) 

The program would be implemented in five evolutionary 
phases with two-year delivery cycles overlapping by one year. 
(29:45) The shortened development cycle was intended to control 
requirements growth. The logic was that, if the user knew he 
would have to wait no more than 24 months and that the phase 
planning provided for new requirements, there would be less 
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pressure to change the baseline in mid-phase. 

The user would be intimately involved with the develop¬ 
ment from phase definition through testing, and would help de¬ 
fine, agree upon, arid prioritize capabilities to be implemented 
in each phase. If the schedule ran out before a part of the 
software was finished, the user would choose whether to slip the 
schedule or to postpone some requirements to a future phase. 

The phasing provided slack for accommodating high priority 
requirements slips from prior phases. 

A distributed computer architecture was adopted to allow 
maximum flexibility of mission and display processing. The 
system would rely to the maximum extent possible on unmodified 
commercial off-the-shelf software and hardware from a single 
vendor. Using a single vendor was intended to be a risk-reducer 
as well as a force-multiplier. Since all interfaces except the 
external world would be through one vendor's standard products 
and protocols, a single entity would be responsible for correc- 
ti,n ; system-level integration problems. The military software 
r, sources would be concentrated on mission software. (30:6) 
Equipment for any phase would be the best production models 
available for mass purchase. Staying close to but not at the 
state of the art would bring the most current technology to the 
Cheyenne Mountain user. 

As discussed in the previous chapter, extremes of 
computer system security had hurt other programs. Unless NORAD 
was willing to pay for it in both cost and schedule, no 
elaborate security measures would be implemented. Should 
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security implementation be required, only commercially available 
security packages from the vendor would be used, and these only 
when their use would not degrade overall system performance. 

Such a choice would allow the vendor to maintain its security 
packages under normal vendor configuration control. (30:6) 

The operational system would be tested on a full-up 
system configuration test-bed located away from the operational 
environment but able to be connected to the current system test¬ 
bed. (29:19) This allowed as realistic testing as possible 
short of the operational environment. Each phase would be 
prototyped starting with displays, since a good display would 
mean more accurate specification, more on target coding, and a 
happier user. 

Implementation of ADOC within 24 months was selected as 
the Phase I challenge. (29:5) The baseline system needed to be 
expandable to accommodate subsequent phases; it was partitioned 
into communications processing, mission processing, and display 
processing. The existing Communications System Segment (CSS) 
was to be used for connection to the external air surveillance 
and control systems. Phase I (ADOC) would be connected in 
parallel with the 427M system, allowing the operators a choice 
of which system to use for air defense. Vendor communications 
buses would interconnect the Phase I computers and provide for 
the required flexibility and growth. 

In order to move into a renovated NORAD Command Post by 
1990, the remaining command post functions of missile warning 
and space display needed to be accomplished on Granite Sentry 
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equipment. (29:5) Missile warning was chosen as the Phase II 
implementation since it was the most time-critical function. 

The 1990, Phase III delivery would consist of the renovated 
command post and the space display software. In 1991, the CSSR 
and SPADOC systems would be delivered in Phase IV. Effort that 
year would be reserved for interfacing these systems and for any 
required clean-up work from the previous phases. In 1992 and 
1993, the Phase V task would be display and interface processing 
related to WWMCCS Information System and the Advanced Weather 
Display System. Additionally, the space processing functions 
would be transferred to SPADDC as the final phase of SPADOC was 
delivered. The overall scope of Granite Sentry was ambitious. 
Each year would see at least one software release, and each 
program would require interface to a data source outside the 
Granite Sentry system. 

The planning team attempted to counter potential 
problems in two ways. First, the effort was kept as modular as 
possible after 1990 in order to facilitate the movement of major 
programs should one of the interfaces announce a slip. Second, 
the workload in these years was light enough to allow time for 
true deficiencies to be completely reworked. The plan was 
approved by both AFSPACECOM and ESD senior staff on 10 November 
1986, and the program moved into the execution phase the next 
spring. 

In summary, the Cheyenne Mountain Upgrades experienced 
the same problems as their predecessors. Born out of 
frustration on all sides, Granite Sentry in effect became an 
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experiment to validate the concept of an ESD and AFSPACECOM team 
as a military management organisation employing the principles 
o-f collocation o-f major SPO -functions with the software 
developer and user, of intense user involvement, and of the 
evolutionary acquisition strategy within the CMC. 
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CHAPTER VI 


GRANITE SENTRY IMPLEMENTATION 

PHASES I AND II 


Although the senior staff had agreed to the shared de¬ 
velopment program, there was much discussion about 
responsibility among the sta-f-f during the -first six months after 
the reorganization of Granite Sentry. Some organizations felt 
that the SPO should perform all work necessary to execute 
Granite Sentry, leaving AFSPACECOM merely to monitor and assume 
the role of critic. Others recommended that AFSPACECOM perform 
the work itself reducing ESD to a monitoring role. The program 
office believed that such unbalanced division would be 
counterproductive and would tend to relieve either AFSPACECOM or 
ESD of responsibility. It brought the issue to the attention of 
the AFSPACECOM Deputy Chief of Staff for Systems Integration, 
Maintenance, and Support in July 1987. The following division 
of labor between ESD and AFSPACECOM was then defined. (32:27 
September 87) 

The ESD Program Office would be responsible for all 
Granite Sentry new development. ESD would purchase equipment, 
write software through the AFSPACECOM software house, and be 
responsible for the Granite Sentry side of any interface to 
existing systems. AFSPACECOM would be responsible for coding. 
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testing, and implementing interfaces from Granite Sentry to the 
existing systems. Finally, equipment associated with the 
operational system, such as communications gear, which would be 
used in various stages of the program, would be managed by 
AFSPACECOM. The Deputy SPO Director in Colorado Springs 
represented the Program Director in all but schedule decisions. 
This division assigned responsibility to the agency best able to 
handle the task. (29s49) The AFSPACECOM software effort was to 
be matrixed via a specialised software development division 
dedicated to Granite Sentry. That division would also perform 
ths configuration management required for the software effort. 

Unfortunately, the 40 programmers were not available in 
January 19S7. (29:50) Although it needed at least 10-to-lS 
programmers, only three had been assigned on a part time basis 
by March. (33s5) Consequently, Government Services 
Administration (GSA) programmers were hired to carry out the 
required Phase I design. This was suboptimal from the point of 
view of program management since it was likely that the GSA 
contract would terminate in October 1988, leaving the program 
without the experienced personnel who started the design. 
Further, the GSA contract did not require Ada language 
programming experience, and the programmers had to be trained. 

To stabilize the workforce, AFSPACECOM engaged in a separate 
contracting effort to obtain Ada software developers. 

By the time the GSA programmers were arriving in 
strength, AFSPACECOM freed 16 programmers to begin working Phase 
I. The entire team arrived in May 1987 and began writing speci- 
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ficatioris -far a system design review June. Since -few were 
trained on the systems software or on Ada, the June design was 
inadequate. (34«1> The month of July was spent in training, and 
internal milestones were adjusted. 

By autumn 1987, the lack of Phase II software manpower 
was critical. The problem was briefed to the ESD and AFSPACECOM 
Vice Commanders at the November Senior Review Group. Major Gen¬ 
eral Brandt, the ESD Vice Commander, formally complained of the 
resource problem to Major General Spraker, the AFSPACECOM Vice 
Commander. As a result of their discussion, the Granite Sentry 
Development Office (GSDO) was formed and assigned to the 
AFSPACECOM Vice Commander. The software personnel were still 
matrixed, but their reporting chain was changed to assign them 
functionally to the GSDO. The total number of Air Force 
personnel committed to Granite Sentry was reduced to 25 because 
of AFSPACECOM's other commitments including 427M software 
maintenance. (35:1) 

Contracting problems slipped the Ada software contract 
award to March 1988, placing Phase I and Phase II further 
behind. Resources who should have been coding in January were 
still in training in June. Phase I had lost a total of 246 
man-months, and Phase II was behind by 129 man-months. <36s7) 

As a result of the slow progress, Phase II limited its 
prototyping efforts to displays, and Phase I concentrated on 
coding rather than integration. The whole phasing sequence 
suffered because, in an attempt to make up the lost effort, the 
Phase I designers were kept on Phase I instead of transitioning 
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to Phase II design as the original concept dictated. However, 
keeping Phase I on schedule was important to both ESD and 
AFSPACECOM, and the resource was applied there rather than on 
Phase II. 

While CINC NORAD had agreed upon the Granite Sentry 'con¬ 
cept, the users were skeptical. Their uncertainty manifested in 
427M software changes which NORAD and the AFSPACECOM software 
maintenance house believed were needed in order to keep the 
operational system current and to hedge against possible Granite 
Sentry Phase I failure. These changes necessitated rewriting 
approximately 15,000 lines of Granite Sentry code, which 
absorbed much of the effort that months of overtime had been 
able to recover and which contributed to the eventual Phase I 
slip. (37) To persuade NOF(AD that Granite Sentry was committed 
to deliver a useful system, two things needed to happen. First, 
as with bringing 427M on line, the changes to the existing 
systems needed to be minimised. <38s40) Second, the user needed 
to become very involved with its development. In a large step 
of faith, the SPO and the GSDO resolved to keep the development 
open, allowing the user access to the programmers and system 
whenever possible. 

NORAD did become extremely involved in the display 
system and in software demonstration- . Generals Bourgeois, 
Andrus, and Reed spent a great deal of time refining the display 
requirements. CINC NORAD approved the Phase I displays in June, 
1988 and the Phase II displays in March, 1989. The software 
demonstrations convinced NORAD personnel that Granite Sentry's 
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goal was a satisfied user because- the coders were often able to 
accommodate changes to the system in response to their 
suggestions. The demonstrations also convinced the programmers 
that the user needed the produce and cared for it as a system 
rather than as a set of specifications. However, the user 
tended to fine tune the system before it was finished, leading 
to some animated discussions about schedules and deadlines. 

User involvement accomplished the goal of increasing user 
support, and it illustrated the value of the flexible 
evolutionary approach. (3s19) 

User involvement also reduced program cost. For 
example, the specification required that data for all missile 
launches be available for display, but it did not state the 
timeliness criteria for the term "available for display." A 
strict interpretation could have led to purchasing more 
communications gear and much larger workstations in order to 
meet the tightest display times. At a feasibility briefing, 
NORAD representatives observed that after a certain point only 
summary information was necessary and asked for the 
implementation of summary reporting. (39) As long as the 
individual events were available somewhere in the system and 
were retrievable within a stated time frame, only summary 
information required immediate availability. (39) 

Thus, from the beginning, Granite Sentry Phase I imple¬ 
mented the principles of evolutionary development, military 
management, a teamed SPO with both ESD and AFSPACECOM 
responsible for success, collocation of a deci >ion-making 
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portion of the 5P0 with the developer and user, and intimate 
user involvement. The evolutionary approach demonstrated its 
ability to incorporate new requirements with the user 
determining the delivery schedule. 

The -final -factor which contributed to success o-f 425L 
and 427M was the assignment o-f the user or SPO organisations to 
high command levels. Such assignment did not occur initially in 
Granite Sentry. Manpower shortages and lack of support were 
chiefly responsible for the failure of Phase I to reach IDC in 
December, 19SS. Once the manpower and support problems were 
addressed by forming the GSDO and assigning it to the AFSPACECQM 
Vice Commander, the Phase I project made excellent progress. 
Phase I was turned oyer to test at the end of February 1989, and 
it reached IOC on March 16th. Considering that the real 
development did not begin until July 19S7, the 24-month Phase I 
project was implemented after only a 20-month programming 
effort. 

The Phase II missile warning effort started late because 
the design team was not assigned to Phase II on time. Until 
July 1989, personnel who should have been designing Phase II 
were still assisting the Phase I team with the final ADOC 
release. By this time, however, NORAD had become a strong 
supporter of Granite Sentry and prioritised both ADOC and 
missile warning requirements. It remains to be seen whether 
Phase II and subsequent phases can recover from the Phase I slip 
which was due to the initial lack of resources. 
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CHAPTER VII 


CONCLUSIONS AND RECOMMENDATIONS 

The Cheyenne Mountain system acquisitions have historic¬ 
ally been chaotic and troubled. Traditionally, the user has not 
been involved with new systems until it is too late to correct 
problems easily. As with other acquisitions -for the Department 
of Defense, these programs have suffered from changing require¬ 
ments and specifications which are beyond the state of the art. 
The extremely capable software maintenance organisation has been 
able to transform the system being replaced so that it sometimes 
surpassed the operator's vision of the replacement system. The 
traditional contract structure has also hindered Cheyenne Moun¬ 
tain programs. It is nearly impossible to write a specification 
for a one-of-a-kind system planned for turnover years later. 

The user's real future requirements are difficult to predict, 
and the user's needs change due to software maintenance, 
impacting the contracted baseline. With no intermediate system 
to deliver, the program office must renegotiate contracts to 
meet new requirements, the schedule is slipped, and the process 
begins anew. 

Problrm resolution has been deliberate and slow to act, 
rarely reaching the correct decision in time t.o have positive 
effects on programs. As problems were encountered in each 
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stage, intervention by senior military or civilian officers was 
necessary to get the programs to operational capability. For 
the original NOCOPS, senior involvement was instrumental through 
the Cheyenne Mountain Complex Task Force; -for 427M, the 
Independent Review Group; and for the early Cheyenne Mountain 
Upgrades, the General Accounting Office. Each of these groups 
recognised the problems and recommended specific actions to 
resolve them. These principles were incorpora ed into the 
Granite Sentry agreement, and except for resource problems, the 
principles were vindicated in the Granite Sentry Phase I 
acquisition. 

The following principles influenced Granite Sentry Phase 
I success: an evolutionary acquisition strategy, a teamed ap¬ 
proach with ESD and AFSPACECOM sharing responsibility for 
success or failure, a decision-empowered SPO Deputy Director 
collocated with the user and developer, a user intimately 
involved with the development, and an AFSPACECOM Granite Sentry 
Development Office managed by the military. 

The evolutionary acquisition approach focused the 
program on implementing limited, single phases with short 
development cycles rather than a large-scale, long-term 
development. The short development cycle minimised the affect 
of 427M maintenance software releases on the Phase I development 
and allowed Phase I to maintain parity with the operational 
system. The evolutionary approach controlled current 
requirements growth by providing opportunity for new 
requirements in later phases. It allowed a working system to be 
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used in the operational environment- The two-year phase cycle 
was short enough to minimize both manager and developer 
turnover, reducing the loss of corporate knowledge. Knowledge 
of senior staf f interest in the project inspired the programmers 
and managers to produce a successful project, and productivity 
was maintained at a high level. 

From the beginning of the agreement, the ESD program 
office demonstrated its commitment to produce a solid product 
for NORAD on AFSPACECOM's schedule. Collocating the deputy 
program manager and staff with the developers in Colorado 
Springs streamlined the decision-making process as it had for 
the earlier CMCMO. There was little significant disagreement 
between the Granite Sentry Development Office and the Program 
Office. 

User involvement was crucial. Prototyping provided the 
opportunity for early hands on experience, allowing the user's 
input to make a difference in the delivered product. The 
delivery cycle was short enough that the user who approved the 
specification for a phase saw the delivered system, enhancing 
NORAD's desire to participate. The impact of NORAD's 
involvement in the teamed workforce cannot be overstated. 

The Granite Sentry Development Office became the focal 
point for AFSPACECOM after the office was assigned to the Vice 
Commander. As with the final 427M and CMCMO organizations, when 
the vice and the general staff demonstrated interest in the pro¬ 
gram's success and became intimately involved, the rest of the 
staff followed suit and progress was made. The single organiza- 


39 


tion -for implementation placed much responsibility on the de¬ 
velopment office, but allowed the freedom to deal with the staff 
and to make rapid decisions. The contractual structure allowed 
military management to focus the contractors rapidly without the 
delay of contract renegotiations. 

The synergy and balance afforded by the above factors 
made the implementation of the Air Defense Operations Center a 
success. Without any one of them, ADOC could easily have joined 
the ranks of other troubled Cheyenne Mountain programs. Should 
any of the factors change significantly, AFSPACECOM and ESD 
should again meet at senior levels to ensure that a correct 
balance is again struck. 

A single integration organization with decision 
authority for Cheyenne Mountain should be appointed. The 
organization should have power to immediately address and direct 
solution of Cheyenne Mountain integration problems. It should be 
composed of both ESD and AFSPACECOM personnel. To not take 
action is to ignore the lessons of the past 24 years and three 
major projects. 

The negative influence of current system software 
maintenance changes needs to be controlled. NORAD and 
AFSPACECOM should take a stronger stand to control change. The 
maintenance organization would still be used for emergency 
software work, but should concentrate on influencing the new 
systems before it assumes maintenance responsibility of a 
problem at IOC. Last, the other programs and their eventual 
replacements should be organized in an evolutionary development 
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structure. No specification is perfect and 


user can ever be 


expected to truly know what he wants until he sees what he gets. 
Acquisitions should first deliver an achievable basic system 
followed by controlled software and hardware enhancement with 
user involvement in an evolutionary approach. This is the 
optimal vehicle for ensuring that the user gets what he needs to 
carry out the vital NQRAD mission. 
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GLOSSARY 


ADCOM 

- 

Aerospace Defense Command 

ADOC 

- 

Air Defense Operations Center 

AFSC 

- 

Air Force Systems Command 

AFSPACECOM 

- 

Air Force Space Command 

BMEW5 

- 

Ballistic Missile Early Warning System 

CORDS 

- 

Command Center Processing and Display System 

CCPDSR 

- 

CCPDS Replacement 

CINC 

- 

Commander in Chief 

CMC 

- 

Cheyenne Mountain Complex 

CMCFTR 

- 

CMC Final Technical Review 

CMCMO 

- 

Cheyenne Mountain Complex Management Office 

CMU 

- 

Cheyenne Mountain Upgrades 

COC 

- 

Combat Operations Center 

CSS 

- 

Communications System Segment 

CSSR 

- 

CSS Replacement 

DIP 

- 

Display Information Processor 

DOD 

- 

Department of Defense 

ECP 

- 

Engineering Change Proposal 

EOC 

- 

Equivalent Operational Capability 

ESD 

- 

Electronic Systems Division 

GAO 

- 

United States General Accounting Office 

GSA 

- 

Government Services Administration 

GSDO 

- 

Granite Sentry Development Office 

IDHS 

- 

Intelligence Data Handling System 

IOC 

- 

Initial Operational Capability 

IRG 

- 

Independent Review Group 

MEBU 

- 

Minimum Essential Back Up 

MWBP 

- 

Missile Warning By Pass 

NCCS 

- 

NORAD Command and Control System 

NCR 

- 

NORAD Command Post 

NCS 

- 

NORAD Computer System 

NCSR 

- 

NCS Replacement 

NOCOPS 

- 

NORAD Combat Operations System 

NORAD 

- 

North American Aerospace Defense Command 

SAC 

- 

Strategic Air Command 

see 

- 

Space Computational Center 

SPADOC 

- 

Space Defense Operations Center 

SPO 

- 

System Program Office 

SSC 

- 

Space Surveillance Center 

USAF 

- 

United States Air Force 

USSPACECOM 

- 

United States Space Command 

WWMCCS 

- 

World Wide Military Command and Control System 

425L 

- 

NOCOPS 

427M 

- 

Cheyenne Mountain Improvement Program 

496L 

- 

Space Defense Computational System 
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